Typically, when endpoints of a network application wish to communicate securely, they negotiate a secret key that they will use to encrypt and decrypt their messages. This negotiation is usually implemented as a multiple-message “handshake.” One side of the connection initiates this process by sending a specially encoded message indicating that it wishes to acquire a secure communication channel. After agreeing on parameters for the connection, the two sides exchange segments of data that, when combined, allow each side to derive the same symmetric key used for securing application data. It is difficult for other parties to derive the same key by observing the handshake traffic.
A fundamental aspect of this key negotiation is the sequential ordering of the handshake messages. If any message is received out of order, the connection will fail. This is not a problem for applications in which requests for connections are sent from clients to persistent servers, such as in web and mail service. Most security protocols are designed with this use case in mind, and assume that endpoints already know whether they are client or server. In peer-to-peer (P2P) environments, however, where the roles of client and server are not predetermined or fixed, these handshake protocols can fail because it is not clear which side will begin the negotiation (and assume the client role). In a P2P environment, any two peers may wish to establish a secure communication channel. Two peers may attempt to negotiate secure channels with each other at the same time, simultaneously sending handshake initiation messages to each other. In this case, both peers assume client roles, and when the initial handshake messages reach their destinations, both connection attempts will fail on protocol errors, because both sides were expecting server responses.
Several protocols exist that implement key negotiation between endpoints. Some, such as IPSec, operate at the network layer, and provide point-to-point encryption and authentication without modification of the application code. Network-layer protocols, however, require operating system or hardware support and are not available in all environments. This is particularly true of embedded environments with minimal operating systems and limited resources, such as telephony equipment. In contrast, programmers can implement transport-layer protocols directly, without the need for operating system support. One such example is Transport Layer Security (TLS), commonly used on web and email servers. Regardless of the layers at which they operate, existing protocols, because they were designed for traditional client-server paradigms, suffer from the above described failure to resolve secure connection negotiation errors in P2P environments.
Some work exists, such as Kok 2006, that attempts to relax the client-server model in network-layer protocols, particularly IPSec. This work, however, makes certain assumptions about the environment in which it operates, such as the presence of an online authentication server, that may not be universally applicable. Additionally, there are certain performance implications to the existing approaches that are undesirable in an environment with limited resources. Particularly, there is a significant increase in network traffic and computational load because the adjustments to the protocol are applied in all cases, regardless of whether or not a role conflict exists.